Skip to content

Add native MCP server to TrailBase - #276

Draft
ignatz wants to merge 4 commits into
devfrom
mcp
Draft

Add native MCP server to TrailBase#276
ignatz wants to merge 4 commits into
devfrom
mcp

Conversation

@ignatz

@ignatz ignatz commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Squash rebase of the latest (native) changes of https://github.com/trailbaseio/trailbase/pull/262/changes#diff-3009e2cec212fff3b4c6741f36eba2016178db426fd526cd3fbd861a9f6236b5

Mostly just wanted the starting point for review.

Add OAuth login flow for native MCP

Replace MCP sidecar with native deployment

Add native MCP schema and config tools

Bind OAuth tokens to the MCP resource

Scope MCP authentication to the MCP route

Clarify portable MCP client configuration

Use localhost in MCP quick start

Use depot flag in MCP deployment examples

Explain native MCP deployment arguments

Add local and public MCP client examples

Explain MCP connection naming
@ignatz
ignatz marked this pull request as draft August 12, 2026 16:46
@ignatz
ignatz force-pushed the dev branch 9 times, most recently from 86865e6 to 035262c Compare August 25, 2026 13:22
@ignatz
ignatz force-pushed the dev branch 3 times, most recently from 8c38ebb to 6fcf273 Compare August 28, 2026 12:02
@ignatz
ignatz force-pushed the dev branch 3 times, most recently from a7058d2 to f24291b Compare September 4, 2026 13:10
@ignatz
ignatz force-pushed the dev branch 3 times, most recently from 9cdc41b to f34e02d Compare September 11, 2026 18:16
@brigon-dev

Copy link
Copy Markdown

Thanks for landing trail mcp. The OpenAPI-generated tool list solves the exact drift problem I couldn't with a hand-written catalog, and stdio-only is the right call for how most IDEs actually connect.

One gap I'd like to propose closing, additively, without touching the stdio transport or tool generation. Right now getting a token into trail mcp means either --user plus local depot access, or manually copying a token out of the admin UI's profile dialog into TOKENS=. For a remote server that's the one piece of friction left. Most hosted MCPs (Stripe, AWS, etc.) handle auth so the browser pops up once and everything after is automatic.

Proposal: add a login mode to trail mcp using the loopback pattern gh auth login / gcloud auth login / aws sso login use:

  1. trail mcp generates a PKCE pair and starts a short-lived HTTP listener on 127.0.0.1:<random port>.
  2. It opens the user's browser to TrailBase's existing AuthorizationCodeFlowWithPkce login page (already used for browser app clients) with that loopback address as redirect_uri.
  3. User logs in on TrailBase's real login page. trail mcp never sees a password.
  4. TrailBase redirects to the loopback listener with the code. trail mcp exchanges it for tokens directly and caches them locally, refreshing silently the same way --user mode already does.

The one server-side change this needs: validate_redirect_impl in crates/core/src/auth/util.rs already special-cases loopback hosts (127.0.0.1/::1/localhost, any port), but only when state.dev_mode() is true. I'd propose that bypass apply unconditionally, which is the standard justification behind RFC 8252's native-app redirect handling. Anything that can bind to localhost on the user's machine already has local code execution, so trusting a loopback redirect there doesn't add new attack surface, even in prod.

Nothing here touches rmcp-openapi, the tool schema, or the stdio transport. It's purely a different way for trail mcp to acquire its token, opt-in alongside --user and TOKENS. Happy to put up a draft PR if this direction looks reasonable to you first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants